This is what happens when the math on speaking doesn't really all add up.
Well, hello.
Well, hello.
You ready to do this?
Yeah, I'm ready to do this. Let's do it.
Do you want me to stand up or?
Oh, absolutely.
Hey, you know what? You're the boss.
Assume the position.
No, no.
All the more reason.
All right, guys. It's up to a vote.
Does he keep his pants on or does he spread his ass?
Spread your ass.
Spread your ass.
No, fuck you guys.
Let's do it.
Yeah.
Two feet past the ass.
All right, all right. Let's do it.
It's all about fun.
Thank you.
One forever. One forever year, right?
Tag's off.
21, right?
Yeah.
Ow.
Oh.
Pull it up.
And slip up.
Ah, that's good.
Oh, shit.
Ow.
All right.
All right. All right. All right.
Minus for science.
This is taking—
finish what everybody got.
This is having fun.
It's starting to really suck.
I thought I'd like it.
I liked it for a little bit.
John, you fucking suck.
No, no, you gotta get the rest of it, man.
No, no, no, we're at 17.
You guys want to see me finish counting?
All right, ready?
18!
Okay, Ong is my nice friend.
Ah!
All right, science time!
Enough spanking.
All right, enough fucking around.
We're going to do science now, all right?
Yeah, yeah?
Oh, okay.
Ow.
Thank you, Ong.
Anyone else?
Oh, Lord.
Ah, okay, science.
So, uh,
I'm a PhD student from Columbia University.
And this is my research.
Why is your voice shaking?
It's my butt hurts.
And this is terrible.
Okay, so,
the name of my talk is Stepping Pones,
Adventures in Full-Spectrum Embedded Exploitation and Defense.
So the defense part is really important.
This is really what I want to talk to you guys about.
And here's why.
Oh, and by the way, the slides are not on the DVD.
It's on our website.
And it's, like, 100 megs.
Because unicorns are magical creatures which cannot be compressed at all.
So, sorry about that.
And this is our typical talk.
You know, this is what I usually do.
First, we say, hey, look, you know, we find this bright, shiny thing that we want to play with.
And be it a router, a car, or a phone, or a printer, whatever it is.
We talk about our motivation for wanting to do this sort of thing.
And then we spend a lot of time in Fail Shack, you know, figuring out all the different ways of not...
Ow. Owning. Owning these devices.
We fail when we fail.
And after a while, we finally succeed.
We find that one vulnerability.
We build that one exploit that works.
We're really excited.
And we keep, you know, we spend some time during the presentation talking about it.
And then comes the bad news.
Okay, the bad news is this thing is everywhere.
The fix is really hard.
You know, this thing runs our lives.
And it could potentially have very big impact that's terrible for the world.
And then we feel bad for saying that.
So we say, well, it's okay, actually.
We have this thing called duct tape.
So we're going to duct tape this thing up by unplugging it.
We're going to get it from the network.
Or let's just not use it in the way that it's intended to.
And hopefully your house won't fall down tomorrow.
And then, you know, me, I usually have pictures of cats and things I find on Google image search like 4 o'clock in the morning for harmless copyright infringement.
And during, like, the last two minutes of the talk, right, we always have this slide that says, wouldn't it be great if we had a real solution?
You know, a solution that's not just duct tape.
That actually fixes the fundamental insecurities, the problems, the reasons why we have the problem that we presented on.
And then we say, okay, goodbye.
Have a nice day.
And we do it all over again.
But the real solution is never really presented, usually.
So I'm happy to say today we worked really hard to make this talk a little bit different.
I'm going to spend about 47% of this talk on the offensive side of our work.
You're going to see PolyCUC's malware propagation.
And by that, I mean malware on embedded devices that propagate from one type of device to another, like a printer to a phone, from a phone to a router, and vice versa in full mesh configuration.
And then we're going to spend a lot of this time, as much time as I can.
On the defensive technology that we've built at Columbia University, that we're commercializing through a little company that is called Red Balloon Security, the defense is called Software Symbiote, and it's essentially the product of my, the five years of my Ph.D. work, you're about to see it live on stage, in what amounts to basically your typical modern office.
And then we're going to spend some time showing you pictures of unicorns and other things that I find on Google image search.
So, HumanCast.
This is my Ph.D. advisor and co-founder of Red Balloon Security.
We haven't seen him since Black Hat.
We don't know where he is.
Michael Costello is a fantastically beautiful man, a designer by day and a scientist by night.
This is Jadon Cotteria, who is also a research scientist at Red Balloon Security.
And here's me, getting spanked on stage and such.
And special guest appearance by Mikey Drop Tables, who is the mayor of Pwn Town, which is located between Quarth and New Jersey, so halfway between.
And that's not all.
So, we have a lot of gear in front of you, we have the cast of machines, and this is stuff that you probably use every single day.
You may or may not see them, you know, on your desk, but we all use it in our modern offices.
So, we have the 2821 Cisco router.
This is probably something you'll find in the closet somewhere, right?
And you'll have one of my favorite printers, the HP 2055 LaserJet, and the Cisco phone, right, the Cisco 7961.
And today we're going to show you a zero-day that we're going to drop at Black Hat, but we're going to show you here today.
It's called the Cisco...
8961, so this is the bright, new, shiny, sexy, new Cisco phone that's almost twice as expensive, but it's really nice.
It also has a zero-day, that's fun to talk about.
And we're going to show you something on the 1841 Cisco router, and we're going to talk very briefly about the work that we've been doing recently on the Avaya IP phone as well.
Now, this is the configurator, you know, this is an image that we all know, right?
You have your big, bad internet, you have this firewall, and inside you have the intranet where you're super-safe.
And Pwn Town is on the right side of internet.
This is where Mikey Drop Table lives.
So he doesn't really know anything about your intranet, right?
To him, this is a mystery because he can't really send any packets to do recon through the firewall from outside in.
This is how we always set things up.
But he can make an educated guess that you probably have a printer somewhere in your organization.
So this is what he does, he's very clever.
He's going to make a fantastically impressive resume, and someone in your organization is going to be so compelled by this resume that they're going to print this out.
And this is a vulnerability that we talked about a year and a half ago, which has been patched by the...
by the vendor, where a print job can change the entire firmware on the printer itself.
And that's because you can pack firmware update files inside print jobs in the printer, which just interpret the firmware update and flash its firmware.
Okay, so that's been talked about.
That vulnerability has been patched in theory.
But once he gets onto the printer, now he has a physical stepping point into your intranet from the outside.
And what he does is he will then...
Oh, so why am I talking about this vulnerability, right?
It's been fixed.
We talked about this chaos.
Uh...
Two years ago, but it turns out we scanned IPV4, looking for publicly accessible, vulnerable LaserJet printers on the internet.
And after 14 months, 14 months after the initial security patch was released by the vendor, and I think they released something like three dozen patches for every single LaserJet model they made,
we found that only seven and a half percent of all the printers on the internet has been patched against this vulnerability, right?
So if you find, you know, a zero-day on something like Firefox or Chrome, you know, you have maybe a weak window
where that vulnerability is actually useful.
But on the embedded side, this is absolutely not the case.
And it's because we don't have the same update infrastructure that we do on general-purpose computers.
So the vulnerability that I found on this LaserJet printer a year ago, right, a year and a half ago,
will still be something that your organization will probably be vulnerable to today, right?
And that's just because people don't patch the firmware on their printers.
It's difficult, it's cumbersome, and nobody likes to do it.
So with this vulnerability, what he's going to do is he's going to create a reverse IP tunnel out the firewall.
So that he can get command and control through this tunnel from outside, from PwnTown, into the internet.
And from there, he's going to send the printer a couple of commands to do reconnaissance on the network to figure out what other embedded devices there are.
And using what he knows about the vulnerabilities and exploits he has about those embedded devices, right,
we're going to show how you can actually propagate through the network, compromising all of these embedded systems
without ever touching a general-purpose computer where you have host-based defense of any kind, right?
So, you know, we've done a few of these.
You know, we looked at the printer.
We looked at...
the router, and we looked at the various phones.
And it turns out, if you just sit down with an embedded device, if you focus on that one thing, finding vulnerabilities isn't really all that difficult.
And I have to put that in air quotes.
I mean, it's not easy, but you have the physical device.
You have all the time in the world.
You can take it apart.
You can figure out how it works.
So the idea was that, and this is the page I put in the first page of my candidacy document for Columbia,
that my theory is that polyspecies malware propagation is certainly coming, right?
We have the offensive capability.
We have the ability to exploit all these different types of devices.
The logical next progression would be to take one device and own another one.
But it turns out, you know, polyspecies malware propagation isn't just trivial, right?
There are some challenges that has to be solved in order for this to really work in the real world.
So my goal, right, is, again, to own, let's say, the router, and from there, put malicious implants in every single one of these devices, embedded devices in the network.
And there's certainly some challenges.
And we're going to talk about the three that we really had to solve in order to get this done.
We're going to talk about the three that we really had to solve in order for this to work.
And here's the reason why.
So if you look at the cast of machines, right, we have CISCOs, we have HPs, and we have IAs.
You know, devices from different vendors, these are all proprietary devices.
You're not going to get the source codes for any of this stuff.
The hardware is obviously all specialized.
And on top of that, the architecture, we have MIPS, PowerPC, AVR, x86, ARM, all sorts of different ISAs.
And after that, we have different operating systems.
We have modified Linux.
We have mystery operating systems that nobody really knows very much about.
We have things like iOS, which is proprietary.
And full of mystery.
We have CNU that's kind of like UNIX, but not really.
And we have other things that are just complete mysteries, right?
You know, look at the thing and say, does this thing even have a kernel?
Completely unknown in some cases.
So what I want to say is that take a step back.
We're going to show you solutions to these problems, these challenges that we found, for the offensive side.
But we're really, when you solve the offensive problem, you're solving the dual of the defensive problem.
So we are actually taking the insights we've gotten from building the embedded defensive
technology, software symbiote, to apply this to build an offensive demo.
So we're using the same type of technology for offense and defense, right, in NCAT.
So the very first challenge here is a generalized way of modifying binaries, right?
So, I mean, once you have a device, how do I get the code that I want to run onto the thing in the first place, right?
It's not like I can put, you know, install that EXE on a printer or a router.
That's just not going to happen.
And it turns out we built this automation infrastructure called FRAC, Firmware Reverse
Analysis Console that we presented here last year.
I definitely recommend you check that out.
We've been building on top of it, and it seems to have worked quite well.
So that challenge is more or less solved for us.
The next part gets a little tricky.
And here is the generalized execution problem.
So once you have modification, you can put whatever binary you want in these devices.
Now, the question is, what do you want to execute?
And by execute, I don't mean just single instructions, but I want to put ‑‑ I want to run
semantically equivalent payload on environments that are vastly different, things like
LinuxHernel on MIPS or VXWorks on ARM, and have it all more or less do exactly the same
thing without really a full understanding of the operating system at all, right?
And I'm going to show you ways of doing that.
Once you solve that, there is an actually even trickier problem of getting input and
output to these targets.
So you have OS and hardware agnostic payload of some sort.
How do you communicate to it?
How do I send traffic and receive traffic from this device without understanding how
the network subsystem works, right?
Typically, you figure out, let's say, the end of the driver.
Right?
If the driver works this way, I'm going to hook this specific call, and that's the way
that I can, you know, see all the traffics that are coming in.
But in operating systems that you really don't understand, this is very difficult.
So let's talk about generalized execution first.
Forget about everything you've ever learned about any operating system.
That's why we have this black box down here, right?
This is like X, Y, Z computer.
You know that the memory is roughly organized in this way.
You have some code and you have some data, dynamic data region, right?
Somewhere in that dynamic data region, you
have what's generally referred to as IOMEM, right?
And inside this code, it shouldn't surprise you, but embedded device firmware is really bloated.
It's got a whole bunch of code that really isn't necessary for the operation of that device.
And by that, I mean, you know, debug strings, IGMP, if you don't use that sort of thing,
multicast IPv6 if you're not using it, syslog, and a lot of dead code, redundant libraries
that are linked in through the build process and whatnot.
In fact, you know, Mike and I looked at Cisco iOS, and it turns out if we wanted to rip out BGP and the HTTP server,
it looked like we were able to take out 40% of the iOS binary and still have that router come up and be fully functional
if you just didn't want to use the web server or BGP.
So there's a lot of room to play with.
And on the other hand, there are points inside the code that we know will be executed at a high frequency with high confidence,
right, regardless of the operating system.
And here's a really good example.
The E-RED instruction.
Every time an exception comes up, the E-RED instruction is called.
So if you just mapped out all of the E-RED instructions and hooked that, it's going to work.
It will be guaranteed perpetual control of the CPU.
And there are a bunch of other places where we can look.
Popular functions that are called all the time, mem copy, et cetera.
So put these two things together, right?
We replace the dead code that's not necessary for the operation of the device, whatever it is,
and we replace it with our own payload, right?
This payload is capable of restoring state between itself and the host program.
So think about this as a binary scheduler.
We use some other dead code for dynamic memory regions, stack, heap, scratch area.
And the last thing that we do,
is we hook a whole bunch of intercept points to guarantee that our payload is periodically invoked.
And then that's really the solution to the generalized execution problem, right?
You can compile the code for a specific architecture
and inject it into the environment regardless of the operating system that you're working inside.
Now, how do we solve the input and output problem?
And I'm going to say that we can actually take the solution from the generalized execution part of this
and at least solve the generalized input problem.
The output is still a little bit more difficult.
And this is what we do.
The payload, in this case, that we choose to run is called the packet scrubber.
We're doing an Easter hunt, essentially.
We're going to put this piece of code that will do a linear scan through the I.O. memory region of the device,
regardless of what the operating system is.
We're going to hook a whole bunch of points.
That's going to guarantee that the packet scrubber will be hit periodically all the time.
And as the device receives network traffic, right, packets are going to be copied into I.O. memory.
And in that I.O. memory region,
we're going to detect well-known patterns that we define ahead of time
that we're just going to call command and control patterns.
And as the device operates, right, we pick out these patterns in memory
and then we service them accordingly to our command and control scheme, right?
And how do we get these patterns inside the I.O. memory range?
It turns out it's really easy.
Even if you send a malformed packet of some sort,
as long as the device doesn't have a lot of hardware acceleration,
the entire packet is usually copied into memory range of that device.
And then the processor will analyze it.
It will analyze and decide whether it needs to discard it, quote, unquote, or process it.
And as long as the thing is copied into I.O. memory, our packet scrubber will find it.
So we can send this command and control through, let's say, an ICMP message,
or we can send it through the content of a JPEG picture, right?
As long as that is copied into I.O. memory, our packet scrubber will identify it, right?
So take a step back and think.
Is this something that's specific to ARM?
It's not.
It'll work for MIPS.
It'll work for AVR, x86, PowerPC, whatever architecture.
Now, is this something that will only work for VxWorks?
No.
It will work for LynxOS, the Windows CE kernel, IOS, Big iOS, Little iOS, the Linux kernel inside a DSP program, right?
This is really hardware and software agnostic.
So for completeness, this is the command and control and the command and control acknowledgement packet that we defined for this demo.
You have an envelope that starts with a predefined pattern, and in this case, I used ACAC because my initials, right?
Followed by some metadata.
And then at the end, you have a predefined pattern, and in this case, I used ACAC because my initials, right?
And then we have magic pattern prefaced by a checksum so we can validate that the packet hasn't been corrupted by something that we don't understand about how IOMemory is manipulated.
And inside that, we have the command arguments, various payloads, right?
And this is how both the offensive and defensive demo will work.
You'll see in a little bit.
So put that together, right?
You have the packet scrubber running, right?
You have CNC packets coming in and out of IOMem.
And as these packets are hit, you know, we identify it.
We service the command and control.
And that's how it all works.
And we have it working on MIPS, ARM printers, routers, phones, and you're going to see that today.
And I want to take a moment.
We found out about Barnaby Jack a few days before making this presentation, and we were all super shocked.
So we wanted to do something for him as a tribute in this presentation.
So we've actually implemented the Barnaby function.
And what the Barnaby function does is it takes arbitrary embedded devices as input and it puts its face into the working memory of those devices.
Okay?
And thank you.
We're not done.
We're not done.
We've actually made a modified Barnaby function prime, which does exactly the same thing but in a permanent way.
So to show that not only can we do this through our command and control, we can actually affect real permanent physical destruction of all these devices through our command and control.
So here is a Cisco phone with Barnaby Jack's face right past the Linux loader, right?
Here it is, physical destruction of prime.
So now I want to talk a little bit about how our demo will go.
So MikeyDropTables on the outside, right, eyeing the printer, owns the printer through this reverse IP tunnel, through this resume, establishes the reverse IP tunnel, sends command and control down to the printer to do recon.
Recon will bring back active devices on the network.
We're going to do a whole bunch of fingerprinting to figure out the devices you're actually looking at.
And once we have, we figure out whether this is a Cisco router or an HP printer or a Cisco phone, et cetera.
And using what we find there, we're going to start dropping exploits onto these things and putting our malicious implants that are in there.
That will give us the same command and control capability on all of these devices, okay?
And before we jump into the demo, I really have to say, I'm not allowed to say a lot about what we have done with Avaya.
That's coming soon.
But the JTagulator, I don't know if you guys saw the talk about it, is the super awesome sauce.
Like, this is the coolest piece of hardware I've seen in a while.
If you see Joe, get him, like, a latte or something, but buy, like, ten of his boards.
This is really cool.
And his board made our work really possible.
So big thanks for Joe Grant.
So now, without further ado, Michael is going to start writing the demo, the offensive demo.
MICHAEL GARCIA- I just want to say I really love this community.
It's 1 o'clock, 1.30 now on a Sunday afternoon, the last day of the conference.
And the room is packed.
I mean, this is great.
Like, you should all give yourself a round of applause.
Please.
And there's going to be a little bit, a very tiny bit of audience participation here.
So...
You know, when that happens, please, everybody, just shout out the obvious answer.
All right, so we're going to Ponetown.
MICHAEL GARCIA- Okay, so everything that we're doing here on stage right is Ponetown.
So this is where we're going to put our offensive payloads.
And then after that's done, then we're going to come to the stage left over here and do defense.
So I'm going to bring up my server.
We've already sent our resume to the printer.
It has been ‑‑ it's rebooted.
And it's going to build its reverse tunnel connection out through the firewall,
out to where Mikey Drop Tables is living.
So we've got our tunnel connected.
So we can now bring up our offensive console.
All right.
And we already see that we have the printer in here.
And so everything that we're going to be doing here, and all of you see this at the beginning, but every command that we're doing, we're going to be doing.
we're doing or almost every command that we're doing is we're sending commands through the
command and control tunnel to the printer to have the printer instructed to do different
things. So what might be the first thing that we want to do? So we've got our printer. We
know about this on the network. But we want to find ‑‑ we want to do reconnaissance
on the rest of the network. So we're going to do a sin scan on the printer on port 23.
And we're instructing the printer through the tunnel to do a sin scan. We've spoofed
the IP address so all the resets are coming back to us. And we can find out a number of
devices on the network. And right now we see we have a number of IP devices. And I apologize
for the formatting for the screen size. But another thing that you're going to notice
is that the printer now has a fingerprint. And this is a memory fingerprint. So when
our rootkit is on there, we can do a checksum over memory.
And then use this fingerprint as a key into a database that we have precomputed offline
a number ‑‑ a bunch of information on these devices. And here we know that it's
an HP LaserJet 2055 DN running firmware from March of 2010. And this might be another
good time to ‑‑ or this might be a good time to note that this work that we're doing
on the printer is nothing new. This is not a new exploit. This was presented at 28C3,
print me if you dare. And there was an NDSS 2013 when firmware modifications
attacked.
We're making the printer do a lot more things during this presentation.
So now the next thing that we want to do, now that we have an idea of some devices on
the network, is that we want to find out a little bit more information. We have some
layer 3 information. We want to get some layer 2 information. Because that's going
to help us in the next stage of our attack. So we're going to ask the printer to give
us a IP to MAC address mapping of these various devices. And then looking at the first six
bytes of the MAC address, the OUI, we can find out what vendor these are. We have an
HP. We have a couple of CISCOs on here. We also have one target on here, Recon 4, which
is a Cisco. For the purpose of the demo, know this is a IP phone. We're going to rename
recon 4 and phone 2. And what we're going to do, we're going to try to SSH into this
phone. We're going to put a phone in just in case. And then we're going to put a 64-bit
And we're going to try to ‑‑ because we know that the phone is going to be running
SSH.
And we're not going to try to log into the phone by guessing a user name and a password.
We're going to take advantage of a feature on these phones is that every single time
you attempt to SSH into them, they ask their pre‑configured TFTP server for an authorized
keys file so we can do key‑based authentication on this.
What we're going to do, though, is instruct the printer to ARP spoof the phone, making
it think that a device that we control on the network is, in fact, the TFTP server.
And that's going to be the printer.
So one of the things that the printer does in addition as part of the packet scrubber
looking for these magic patterns of command and control packets is it looks for TFTP authorized
keys request files.
And it already has in memory a nicely formed one packet TFTP response file of an authorized
keys file.
It just has to populate a couple of fields.
Which key are we going to use, Mike?
We're going to just use a key that we built ourselves.
So we would be able to authenticate.
That's nice.
Mm‑hmm.
So we're going to poison phone 2 with the IP address of the TFTP server that we learned
through reconnaissance.
But first, before that, I need to bring up a proxy.
I'm going to wait for the ‑‑ oh, the proxy already connected, very good.
And we're going to ‑‑ so we're going to ARP poison it and do it again for good
measure.
So now Mike is going to SSH through the local host in Pwn Town, through the proxy, through
the printer, to the phone, right, and spoof the authorized keys file as it's being requested
and then get console access to the phone from the Internet through the printer.
Okay.
And if this works, we should get a shell login prompt and not an SSH password prompt.
Yes.
Ta‑da!
Wait.
He's typing a super secret password.
How do you know what the secret password is?
What the username and password is.
Cisco documentation informs.
But can you not just change that password?
No, because if you change it, then the checksum changes and the phone resets itself.
And the password comes back to the way it was before.
That sucks.
Okay.
So this, we find out, is a Cisco 8961.
It's running 921 software.
This is not ‑‑ this is recent, not the latest software on it.
There has been a release.
Or there will be forthcoming releases.
That kind of puts epoxy in some of the holes on this but doesn't actually address the problem
that we're going to show you all today.
But here we notice that this is a phone.
This is a general purpose computer.
This has to look like a phone that's running a Linux kernel on here.
And we're not going to go over everything that we tried and failed to do to get root
on this thing.
We're going to cut right to the point.
We found after looking at how the phone boots up that it uses NAND devices.
And one of the things that we noticed, and this is just one of the devices, does anybody
see a problem with the permissions ‑‑ Just shout it out.
There you go.
Yes.
And we did this before seeing Monk's talk about NAND flash vulnerabilities.
So we could have done this in a lot more elegant way.
But he didn't send the slides before and we didn't know about it.
So we did this in the most monkey way possible.
Yeah.
So if anybody didn't hear it, MTD4 has world right permissions on it.
And what we could do is if it has world right permissions, as ordinary authenticated default
non‑privileged user, we could write to this device.
In theory, right?
But, Mike, we don't have any tools to do that.
We're going to have to compile it or download it.
That's going to be a lot.
How are we going to do this?
Actually, it's really convenient that Cisco had already packed for us a number
of flash utilities.
So we could erase the device and find out if ‑‑
No way.
So they give us permission to do it.
And the tools that allows us to do it.
That's pretty cool.
Yeah.
And there's not only flash erase and info, but we also have a number of NAND tools that
we ‑‑ Wow.
That's really useful.
But, okay, come on.
Like, this file system is going to be, like, megs and megs large.
I mean, how are we going to ship it to the phone?
How are we going to pack it?
It sounds all very complicated.
It really isn't.
You can do all of this stuff offline.
And you could pack one file in a very small file system, fit into one 4K block and transfer
it over the phone using TFTP.
Which is also on the phone.
So you don't have to compile any of this stuff.
All the tools are there.
So there's the old day.
I mean, you know, when I found it, this was a little disappointing almost, right?
Because we've gone from the CNU kernel, which is a proprietary thing that very few people
have looked at, to a much more secure environment, the Linux 2.6 kernel with all of the security
patches backdated to the thing.
And yet owning this phone has become somehow easier, right?
So something is wrong here.
And it's just human error, really.
So what we might want to ‑‑ what would somebody want to pack into one of these files?
Maybe a little root popping set UID root program.
So if we look at who I am now, I'm default, but ‑‑ I really don't type this slow.
Everything is going over this proxy.
Okay.
All right.
All right.
All right.
All right.
All right.
We're root.
Ta da.
Okay.
So that's all it took.
You know, you didn't actually even have to compile anything.
You just log into the phone, you look around and build this 4K file system, and there you
go.
You have it.
And now we're going to switch over to our command and control demo.
For good looks, you know, we promised that this is going to be a command and control
infrastructure that ‑‑ oh, by the way, I have to say, now that we're on a Linux
operating system, we're home free, right?
We can start doing all the stuff that we know how to do.
So now going from a Linux phone to a computer.
Compromising the printer using the initial attack vector becomes all of a sudden very
simple.
Now we're going to load up all of the devices we have our command and control implant on.
And for good measures, we're going to add two other devices, the Cisco 2821 router and
the Cisco 1841 router, just to show that our command and control will work on phones, printers,
and all sorts of different routers as well.
Okay.
So through the tunnel, the first thing that we want to do is heartbeat all devices, see
if our root kit is listening.
And so ‑‑ And, of course, we're also doing this,
again, through the tunnel that the printer is established.
Okay.
So a number of data gets back from it.
Everything responds and says that we're here.
Again, with the memory fingerprints that we were able to take, we can look up a bunch
of info on these things, precomputed offline.
So for instance, let's instead look at the 2821.
We see that we know that it's running MIPS4 Big Endian.
We could find the addresses of various functions.
Okay.
And here we've decided to redact it.
Oh, yeah.
So we've got lawyer pwn and we couldn't show you any of the actual offsets, but they're
there in our database.
Sorry.
Okay.
So now we can do read and write, right?
So let's rock out the Barnaby function.
Okay.
So let's just go directly to reading and writing.
So before running the Barnaby function, just so in case anybody doesn't know typical Cisco
router behavior.
Okay.
So you can enable and you type in the password wrong three times.
This is bad secrets and you're just a regular privileged user and if you do a show version,
you just get to see what the router is running.
But if we run the Barnaby function, this is doing a number of writes to memory.
Let's do it on the 1841 as well.
So now if we do enable, bad secrets.
But notice that's not working.
The problem has changed.
If we do a show ‑‑
Oh, wow.
That's not supposed to happen.
Things are weird and terribly bad in the routers.
Wait, wait.
That's not all.
So we're going to do show version, right?
Yeah.
And if we do show version ‑‑
Oh, look at that.
We've got Barnaby's face in there.
Ta da.
And it's in the 1841 as well.
Right.
So we can do this on ‑‑ and this is because the command and control works the same way
on different architectures, different operating systems.
And we're just given an arbitrary version.
It's a memory write command and we're writing it to the specific location.
And the reason why we know the specific location of the string is because we actually have
precomputed the disassembly of the specific IOS version that we found that we know this
router is running through the fingerprint that we've exfiltrated through the heartbeat.
And we can do this at scale on all of the images from all the devices that we have
under CNC.
Okay.
Let's move on to ‑‑
Yeah.
So let's do the defense demo.
We're running a little bit short on time.
And as promised, I'm going to spend as much time as I can on the defensive side.
So I want to say ‑‑ well, okay, population, Pwn Town, without defense, six, right?
Terrible.
Oh, another fun fact.
It turns out the Cisco ‑‑ the HP printer is really quite a capable piece of device.
This thing can send about 15,000 packets per second, right?
And you can send terrible things.
You can just yak, yak, yak all day long.
And it turns out if you want to DOS a 2821 router using a single printer, you can.
You can peg it to 100% or 98% CPU utilization.
And just ‑‑ that's one printer.
Imagine what I can do with two printers.
And we'll show you that if we have some time.
Right?
Wins all day.
Okay.
So now I want to show you the defense demo.
And this is the thing that I've been spending the last five years of my Ph.D. career developing.
This thing is called Software Symbiote.
And it uses a lot of the same insight that you saw on the offensive side to develop dynamic
firmware integrity attestation in arbitrary legacy‑embedded devices.
We're showing you demos that run on ARM, on MIPS, on Cisco phones, on Cisco routers,
and then on HP printers.
This is really not something that ‑‑ oh.
And we require absolutely no vendor intellectual property.
We take the binary that comes from the vendor.
We require no source code.
We require no hardware modification.
This is not a timing‑based attestation method.
This is not a static attestation method.
This is not proof‑carrying code in any way or in‑line monitoring.
This is something very new that is very flexible.
And you're going to see a demo of this thing working right now on exactly the same hardware
that you saw the offensive demo on.
So we're going to get out of Pwn Town and go somewhere else.
All right.
Thank you.
And then as Mike is setting up, we're going to run through the first phone exploit that
does kernel memory modification, right, and we're going to bring up the symbiote alerting
console that's going to show us dynamic updates to the checksums of the static regions of
code inside all of these devices.
So any piece of code that is modified within static code regions of these devices will
be detected in approximately about 100 milliseconds of detection latency, depending on the speed
of the CPU.
So the routers will have 100 milliseconds or so.
The phone actually has a much faster CPU, so we can actually detect it much, much faster.
Okay.
So we got in here.
We added our routers in.
Again, I apologize for the formatting.
So right now we have the phone, the router.
There's a printer at the bottom.
We'll try to add that in individually at the end.
But for right now we'll show you the phone and the routers.
And so these are routers that are running our symbiote code.
This is all work that's been funded by DARPA.
All of these things are packed together with a utility that we built called FRAC, funded
by CFT.
So thank you very much, Mudge, if you're in the audience or wherever you are.
All right.
So what we're going to do is we're going to go through exploits that we've demonstrated
before, shown before.
There's not much new here.
So the first one we're ‑‑ but what is new here is the symbiote, depending on all
this stuff.
So the first thing that we're going to try it on is the Cisco I2.
We're going to SSH into this thing.
And so the exploit that we're going to be showing here is the same one that we showed
at 29C3 hacking Cisco phones.
So if you want the details on that, please watch that video.
You can find it on YouTube.
Whoa.
Don't walk in front of the speaker.
I'm sorry.
And then the way that this demo works is that we have a file called Pwnbin.
What we do is we change the way that set UID responds so that we get root access.
If you look over here, the Cisco phone, we have one checksum and the secure state is
secure.
But after we go to the phone, we run Pwnbin.
We can then log into the phone.
All right.
And we have root access again.
Please watch the video to see the details.
But now we see that the secure state has changed the Pwn because the Symbiote detected
the change that we made in firmware.
And the checksum has changed.
That's how we detect it.
And you can see the alarms coming periodically.
We actually had to slow down the alarms coming from the phone.
Otherwise it would just flood the screen.
So the alarms can actually come much faster.
But for the sake of the demonstration, we had to slow down the refresh rate a little
bit.
Okay.
And here we're just going to show the 2821 router because of the screen formatting.
But we're going to show the 2821 router because of the screen formatting.
We're not going to be demonstrating a Cisco iOS exploit today.
Along with the Symbiote, we made a small change to the show CDP neighbor command, which in
addition to showing us our CDP neighbors, it also makes the memory modification change
that was part of the Barnaby function to bypass enable authentication.
So if we run show CDP neighbor here, we could see that the router 2821 checksum has changed
and it's changed state to Pwn as well.
Let me see.
Let me see if I can bring up.
Let me bring up the printer quickly.
Let's do the 2821.
It's off the screen.
It would be hard to see.
I can't see.
Well, so what you're looking at here are functionally equivalent devices.
But these are very unique devices in the sense that the phone and the printer and the routers
we've seen are literally the only ones of their kind in the universe that actually has
host‑based defense in real time as the device is running that will allow you to have alerts
that tell you whether the phone and the printer and the router has been exploited with approximately
100 milliseconds.
This is something that's never happened before.
And you folks are the very first people to actually see something like this.
And this is not something that we developed specifically for a specific model of a Cisco
or a phone or a printer.
This is generic technology that can be injected into legacy embedded devices without requiring
any source code, any hardware modification.
So this is something that you can see in a car.
You can see in something that controls the Predator drone or the Mars rover, which also
runs VXWorks, by the way.
The same operating system as the printer.
Okay.
So ‑‑ So that exists.
Yeah.
And with the printer that has a very small proof of concept symbiote running into it,
we can use our command and control rootkit that we had demonstrated earlier and if we
write an image of Hello Kitty into it, the state should change ‑‑
Okay.
Okay.
Sorry.
Oh, there.
There it goes.
So we made a change in memory of the symbiote, picked up on it, checked some change and we
got it.
Ta da.
So that's it.
That's our defensive demo.
I just want to say, you know, so we've accepted host‑based defense on desktop servers for
a very long time now, right?
And, you know, we haven't really started thinking about ways of seriously defending embedded
systems against this type of attack.
So you've seen in the last few years that exploitation of these devices are no longer
a myth, right?
It's no longer that hard that people aren't looking at it.
Now hopefully you saw here that the polyspecies malware propagation part of this thing is
also not a myth, right?
You saw it live on stage.
You saw a printer own a phone, right, and malicious implants on routers, et cetera.
So I think this is the real time that we need to start thinking about real ways of
getting this technology out, host‑based defense on the defenses that we use every
single day in our offices, right, in our defensive networks, et cetera.
So.
A few more minutes.
I'm going to take Q&A in the pool.
So we're going to have some time for that.
But before, can we run the DDOS, the denial of service demo?
Who wants to see a printer peg a 2821 router?
All right.
Let's do it.
This is a lot of fun.
So right now Mike is going to send the denial of service attack command to the printer.
And what the printer is going to do is it's going to send as quickly as it can malformed
TCP packages.
It gets to the OSPF hello address in multicast, right, and when the router sees that it doesn't
know what to do and it gets all scared and the CPU goes all very high and bad things
happen, right?
All right.
So, you know, that's not good.
Right?
You shouldn't have your router running at, like, 98% CPU utilization.
And this is all happening from a single printer.
So imagine, like, a printer and a phone, right?
We'll show that next year.
Okay.
So that's our presentation.
If you want to know more about Software Symbiote or our presentation, check out Red Balloon
Security, www.redballoonsecurity.com.
We have all of the academic papers that discuss exactly how this works, the performance constraints,
the security promises and limitations of our technology, and some demo videos.
And, of course, the slide.
I don't know if I have time to take questions, but Q&A area in the pool.
All right.
And it will probably be about 30 minutes.
Yeah, about 30 minutes.
We'll pack up.
We'll go to the pool.
All right.
Thank you very much.
